Hypertext Transfer Protocol (HTTP) is widely used for communication of hypermedia documents, electronic commerce transactions, and various network management software applications. HTTP servers are now widely deployed for the purpose of transiently linking together computers that are widely geographically distributed into a virtual worldwide “web” of computers and networks. Client computers with compatible HTTP or “web” browser software can retrieve documents from HTTP servers and interact with applications that post or return results and screen displays to an HTTP server. The term “client” can refer to a process that sends a request for a service over the network as well as to the computer device that hosts the process. The term “server” can refer to a process that provides the service in response to the request, as well as to the computer device that hosts the process. As used herein, the term “client” refers to the host device for the client process unless otherwise indicated; and the term “server” refers to the host device for the server process, unless otherwise indicated.
An HTTP communication exposes the information that is communicated to many security risks, such as unauthorized access, eavesdropping, and message tampering. Several approaches are currently used to protect against such attacks through use of client passwords, authentication, and various data encryption methods.
In a first approach, HTTP Basic Access Authentication (as defined in Request for Comments 1945 [“RFC 1945”] of the Internet Engineering Task Force, available at the time of this writing at domain ietf.org) is a method that provides client authentication, but not data encryption and server authentication. In this context, “authentication” refers to verifying that a client or server is what its messages indicate it is. A further disadvantage of this approach is that any client password is sent over the network in clear text with no protection.
In another approach, HTTP Digest Access Authentication (as defined in RFC 2069, available at the time of this writing at domain ietf.org) is a method that provides an enhancement over Basic Access Authentication. The secure one-way hash function known as Message Digest 5 (or “MD5”) is used to protect the password sent to a server by generating a fixed-length hash value from the password. Because the original password cannot be recovered from the MD5 hash value, this method does not work well with centralized authentication protocols, such as RADIUS or TACACS+. Use of these protocols generally involves recovering the original password so that it can be forwarded (using another encryption mechanism) to a centralized authentication server for verification.
In yet another approach, secure HTTP (“HTTPS” or HTTP over a Secure Socket Layer, SSL/TLS) is a method that provides data encryption, data integrity, and client/server authentication. HTTPS is a strong and comprehensive solution, but it requires intensive processor usage as well as significant management overhead and technical expertise to install and maintain authentication certificates. Computationally expensive bulk ciphers such as DES, Triple DES, or IDEA are used for encryption of a data stream.
The cost and overhead associated with SSL and HTTPS sometimes are not justified, especially when the data for encryption is relatively short, such as a client password, or encompasses only selected parts of the stream of communication generated by a particular application. HTTPS encryption is done in a lower logical layer than an application, typically in a socket layer; at this layer, an application cannot selectively control whether encryption is applied to data.
Based on the foregoing, there is a clear need in this field for an alternative way to improve HTTP communication security. In particular, there is a need for an approach that provides both authentication and data encryption that is more secure than the HTTP Basic method mentioned above, and that allows the destination server to decrypt the encrypted data in contrast to the Digest Access Authentication method mentioned above. There is also a need for an approach that does not require use of computationally burdensome bulk ciphers to encrypt data as used by the HTTPS method mentioned above.
It would also be desirable to have an approach that is carried out by an application on top of an HTTP transport layer, in order to allow the application to control which data is encrypted and which data is not encrypted.
There is also a specific need for an improved application-layer encryption approach that can efficiently encrypt small or medium amounts of information such as passwords, credit card numbers, user data entry, etc., under control of an application program. There is a further need for an approach that is resistant to attacks in which attackers can eavesdrop on the communication or launch a plaintext attack.
The past approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.